1. Avant-propos
Nous allons vous apprendre dans ce cours des techniques pour Analyser et Concevoir des Systèmes d'Information…
Nous nous servirons du parallèle avec la réalisation d’une oeuvre d’architecte (comme une maison, cf. [Architecte]).
1.1. A qui est destiné ce document?
Les étudiants du DUT informatique, mes collègues enseignants qui cherchent un document de référence accessible, et … moi-même (pour organiser mes notes diverses)!
1.2. A qui il n’est pas destiné?
Si vous appartenez à une de ces catégories, ce document n’est pas pour vous :
-
vous cherchez un livre de référence
-
vous voulez vous perfectionner
-
vous souhaitez préparer une certification
1.3. Historique
Ce document est la compilation de plusieurs années d’enseignement …
Vous trouverez en référence (cf. Bibiliographie) les ouvrages et autres documents utilisés.
Je tiens à remercier mes collègues qui m’ont aidé dans mon entreprise :
-
Nicolas Belloir de l’Université de Pau et des Pays de l’Adour, Laurent Nonne de l’IUT de Blagnac;
-
le maître d’AsciiDoc : Jean-Michel Inglebert.
1.4. Sur l’auteur
-
Professeur à l’Univesité de Toulouse
-
Co-foundateur de l’association SysML France
-
Membre du comité éditorial de la revue Software and System Modeling journal
-
Membre du Steering Committee de la conférence ACM/IEEE MODELS
-
Chef du département informatique de l’IUT de Blagnac 2009 à 2012
-
Marié, une (merveilleuse) fille
1.5. Comment lire ce document?
Ce document a été réalisé de manière à être lu de préférence dans sa version électronique (au format PDF), ce qui permet de naviguer entre les références et les renvois interactivement, de consulter directement les documents référencés par une URL, etc.
|
|
Si vous lisez la version papier de ce document, ces liens clickables ne vous servent à rien, et c’est votre punition pour avoir utilisé du papier au lieu du support électronique! |
1.5.1. Conventions typographiques
J’ai utilisé un certain nombre de conventions personnelles pour rendre ce document le plus agréable à lire et le plus utile possible, grâce notamment à la puissance d’AsciiDoc :
-
Des mises en formes particulières concernent les noms de personnalités (e.g., Jean-Michel Inglebert), etc.
-
Les références bibliographiques présentées en fin de document (cf. Bibliographie).
-
Tous les flottants (figures, tableaux, définitions, etc.) sont listés à la suite de la table des matière.
-
Les termes anglais (souvent incontournables) sont repérés en italique, non pas pour indiquer qu’il s’agit d’un mot anglais, mais pour indiquer au lecteur que nous employons
1.6. Pourquoi parler de "document"?
Parce que j’ignore la version que vous êtes en train de lire. A partir de l’original, plusieurs versions ont été générées grâce à AsciiDoc :
-
Une version pour le web (Moodle) au format html
-
Une version pour présentation en amphi au format présentation
-
Une version pour impression au format pdf
|
|
Si vous êtes curieux sur la production de document "par programmation", je vous invite à lire la section dédiée. |
1.7. Utilisation et autres mentions légales
Les images qui ne sont pas libres de droit contiennent un lien vers les sites où je les ai "empruntées".
N’hésitez pas à m’envoyer vos remarques en tout genre en m'écrivant ici.
Partie 1 : Généralités
1. Place dans la formation
-
Ce module est central
-
(presque) tous les autres tournent autour (cf. [Central])
-
Fil conducteur
-
-
Le contenu est « flou »
-
Le PPN ne décrit que les compétences
-
Très variable en contenu
-
Soyez critiques!
-
2. Organisation
-
2 intervenants permanents
-
"interchangeables"
-
2 intervenants supplémentaires en TD/TP
-
Découpage Cours / TD / TP
-
3 semestres + 1
-
Pour ce semestre (S1) :
-
16 semaines (devoir en 8ème semaine environ)
-
1H30 de Cours toutes les 2 semaines
-
1H30 de TD chaque semaine
-
3. Généralités
-
Supports
-
disponibles sur Moodle
-
Après ou avant les cours
-
Après (pdf) pour ce genre de supports
-
Avant (distribués en cours) pour les supports « techniques »
-
-
|
|
uniquement une aide à vos notes personnelles |
-
Outils
-
UML
-
WinDesign
-
4. Objectifs
Comme tout le reste du programme enseigné au DUT, ce cours est une adaptation du PPN :
-
Les organisations et leurs Systèmes d’Information
-
Le Génie Logiciel et la façon de concevoir un système de qualité
-
Les démarches/méthodes (Merise), notations (UML ) et outils nécessaires aux futurs métiers qui vous attendent
Le module ACSI se décompose en deux parties principales (Unités de Formation) :
-
Modélisation des Systèmes d’Information
-
Techniques Complémentaires de Production Logicielles
4.1. Modélisation des Systèmes d’Information
-
Objectifs :
-
Connaître les outils de modélisation des systèmes d’information
-
Connaître un atelier de génie logiciel
-
-
Compétences visées :
-
Produire une spécification opérationnelle
-
-
Pré-requis :
-
Algorithmique
-
Théorie des ensembles, relations, logique
-
Calcul des propositions et des prédicats
-
-
Programme :
-
Organisations et systèmes d’information
-
Langages de modélisation
-
Méthodes d’analyse et de conception orientée objet
-
Initiation à l’utilisation d’un Atelier de Génie Logiciel
-
Etude de cas
-
|
|
Ces éléments sont tirés du PPN. |
4.2. Techniques Complémentaires de Production Logicielles
-
Objectifs :
-
Connaître les principes de conception de l’Interface Homme-Machine
-
Connaître les principes de mise en œuvre de la qualité logicielle
-
-
Compétences visées :
-
Mettre en œuvre les principes de conception de l’I.H.M.
-
Mettre en œuvre une approche qualité dans le processus de production du logiciel
-
-
Pré-requis :
-
Expérience en programmation et en modélisation des systèmes d’information
-
-
Programme :
-
Qualité du logiciel : objectif du génie logiciel ; assurance qualité, normes, gestion des
-
projets logiciels et documentation, cycle de vie du logiciel, architecture logicielle
-
Principes et techniques de base des tests : familles et niveaux de tests, outil de tests
-
Interaction homme-machine : prise en compte de l’utilisateur, conception de l’I.H.M.,
-
composants graphiques, choix et recommandations ergonomiques, I.D.E.
-
|
|
Ces éléments sont tirés du PPN. |
4.3. Interactions avec les autres cours
-
Programmation
-
Bases de données
-
Gestion de projet
-
…
|
|
Voici un exemple :
|
4.4. Concrètement
-
Plusieurs matières
-
Plusieurs intervenants
-
Plusieurs supports de cours
-
Organisation
-
Merise
-
UML
-
Systèmes d’Information
-
Génie Logiciel
-
-
Nombreux exercices
-
sujets
-
corrections
-
-
Très nombreux supports Internet
|
|
Rien ne vaut la pratique elle-même! |
5. Fondements
Pour mener à bien le développement d’un système informatique industriel ou commercial, on ne peut pas improviser. Il s’agit d’un travail impliquant un grand nombre de personnes, des enjeux financiers souvent énormes. Le but de ce cours est de vous faire prendre conscience de cet état de fait autant que de vous donner les différentes techniques liées à cette activité. Au nom de quoi pouvez-vous avoir confiance dans les conseils présentés dans ce cours? Il ne faut pas justement! Il vous faut sans arrêt questionner, remettre en cause les idées reçues. Néanmoins, les éléments de ce cours ne sortent pas de l’imagination fertile de son auteur. Je m’inspire principalement de ceux qui ont l’expérience en la matière. C’est pourquoi vous trouverez un grand nombre de références et d’informations pour aller plus loin (généralement des URLs).
L’objectif de ce cours est d’aborder la problématique du développement raisonné (de qualité, sûr, rapide, pas cher, etc.) de systèmes d’information. La méthode choisie est celle des études de cas et des applications concrètes.
Les concepts abordés peuvent se classer en différents niveaux [gram86] :
- stratégies
-
règles de comportement général guidant les choix du développeur (par exemple, obtenir le plus rapidement possible un énoncé exécutable relève de la stratégie "prototyper").
- tactiques
-
décrivent des étapes logiques de développement conduisant à un énoncé possédant certaines propriétés (par exemple, passer d’un énoncé imprécis à un énoncé totalement défini relève de la tactique "spécifier").
- paradigmes
-
sont des étapes élémentaires de la construction d’un programme (par exemple, expliciter une entité par un nom et une définition informelle revient à appliquer le paradigme "désigner").
5.1. Stratégies
On vous parlera ici de méthodes, de cycle de vie, de gestion de projet. Mais nous aborderons cela bien plus tard car dans un premier temps cela va être à la fois rébarbatif et très loin de vos préoccupations.
Pour l’instant retenons des principes simples :
-
Comprendre
-
S’organiser
-
Modéliser
-
S’adapter
5.1.1. Comprendre
Théoricien : individu qui n’est pas de votre avis.
— Auguste Detoeuf
Le problème, l’environnement, les outils à maîtriser, la solution attendue, le domaine métier, etc.
5.1.2. S’organiser
Vingt fois sur le métier remettez votre ouvrage : Polissez-le sans cesse et le repolissez ; Ajoutez quelquefois, et souvent effacez.
Dans les méthodes agiles on parle de "sprint 0". Il est important de bien s’organiser avant de foncer tête baissée dans le travail à proprement parlé.
Voici quelques éléments importants à aborder :
- Démarche globale
-
Quelle démarche allez-vous mettre en oeuvre (Merise, RUP, Agile, personnelle, …)?
- Rôles
-
Qui va faire quoi?
- Environnement
-
Quels outils allez-vous utiliser (modélisation, analyse, développement, test, documentation)?
- Versionnage
-
Il est très important, surtout dans un travail collaboratif, de bien utiliser un outil de gestion de version. Que ce soit pour le code (facile), la documentation (moins évident) ou les modèles (très difficile). Pour le code, le nombre de systèmes disponibles vous empêche d’avoir une excuse (git,Subversion,Mercury).
5.1.3. Modéliser
Ce que l’on conçoit bien s'énonce clairement, Et les mots pour le dire arrivent aisément.
Pour s’abstraire.
5.1.4. S’adapter
Se mettre à jour des techniques. Adapter sa façon de procéder au contexte (au poste que l’on occupe par exemple). Voir [feedback].
5.2. Tactiques
Liste de tactiques :
-
spécifier
-
décomposition (d’un problème en sous-problème)
-
itération
-
induction (construire un énoncé récursif)
-
approximation (organiser la résolution d’un problème en étudiant d’abord un nouveau problème, considéré comme plus simple)
-
généralisation (formuler et résoudre le problème à un niveau d’abstraction plus général pour permettre ensuite un plus grand nombre d’identifications)
-
réutilisation (exploiter au mieux tout travail déjà fait, cf. aussi [DRY])
5.3. Paradigmes
Liste de paradigmes :
-
désigner
-
typer (décrire les proriétés pertinentes d’une entité)
-
affaiblir (transformer un énoncé pour en réduire la complexité)
-
renforcer (compléter un énoncé par des contraintes supplémentaires)
-
décomposer par cas (lorsqu’on distingue plusieurs traitements suivant les données du problème à un endroit donné)
-
sérialiser (pour définir un résultat, utiliser un résultat intermédiaire
xà partir des données, puis exprimer le résultat à partir dex) -
répartir (définir séparément un certain nombre de sous-résultats, qu’il s’agit ensuite de composer entre eux pour obtenir le résultat attendu)
-
identifier (identifier deux problèmes consiste à reconnaître leur identité au-delà des différences de forme de leurs énoncés)
-
paramétrer (faire abstraction des valeurs particulières de certaines entités, parce qu’elles ne sont pas pertinentes pour l'élaboration de la solution visée)
-
représenter (choisir, pour certaines entités, les types, les relations et le moyen d’expression adéquats)
Les tactiques sont des compositions de paradigmes. Ainsi, la mise en oeuvre de la tactique d’approximation consiste à appliquer le paradigme affaiblir, et le cas échéant le paradigme renforcer pour revenir au problème posé.
5.4. Le Manifeste Agile
Le Manifeste Agile (Agile Manifesto [HighsmithFowler2001]) est un ensemble de principes (voir aussi [1030005] pour une analyse plus récente).
Notre plus haute priorité est de satisfaire le client en lui livrant rapidement, et ce, de façon continue un logiciel de qualité.
À intervalles réguliers, l'équipe réfléchit sur une façon de devenir plus efficace, puis adapte et ajuste son comportement en conséquence.
Partie 2 : Merise
Plan de cette partie :
-
Pourquoi une méthode ?
-
Pourquoi MERISE ?
-
Concepts clés et principes de bases
-
Les flux
-
Les traitements
-
Les données
Note: Dans nos enseignements de DUT Informatique, cette partie est abordée en 3ème semestre.
1. Pourquoi une méthode ?
-
On peut faire ce qu’on veut :
-
si on est seul
-
si on a le temps
-
si on n’a pas de comptes à rendre
-
si les erreurs n’ont pas de conséquences
-
-
Pour tout le reste
-
besoin de communiquer
-
besoin de s’abstraire de la complexité
-
besoin de rendre des comptes
-
2. Pourquoi MERISE ?
Ce qu’on peut dire de Merise :
-
méthode très utilisée en France
-
des générations de programmeurs l’ont apprise
-
elle permet donc de servir de référence pour les autres approches
3. Concepts clés et principes de bases
-
Approche systémique
-
Différents niveaux d’abstraction
-
Différentes considérations ("vues")
-
Démarche globale
3.1. Approche systémique
On complète Descartes :
-
logique ternaire ou conjonctive (qui relie) plutôt que logique binaire ou disjonctive (qui sépare)
-
centrée sur le but à atteindre (finalité) plutôt que sur la recherche des causes (causalité)
-
relationnelle et globale plutôt qu’analytique
-
orientée par le présent/futur (prospective) plutôt que par le passé/présent (déterminisme)
-
ouverte sur la diversité des réalités et la pluralité des solutions plutôt que sur la quête de certitudes et de réponses "universelles"
-
propice à l'émergence de la nouveauté et à l’invention (moins réductrice)
3.2. Différents niveaux d’abstraction
- Conceptuel
-
-
quoi?
-
- Organisationnel
-
-
d’où?
-
qui?
-
quand?
-
- Logique
-
-
quand? où? comment?
-
indépendamment de l'"implémentation"
-
- Technique
-
-
comment?
-
le concret
-
3.3. Différentes considérations ("vues")
- Flux
-
-
ce qui circule
-
architecture
-
- Traitements
-
-
dynamique
-
comment le système se comporte
-
- Données
-
-
statique
-
ce qui est manipulé
-
3.4. Démarche globale
Intersection entre vues et niveaux
| Flux | Traitements | Données | |
|---|---|---|---|
Conceptuel |
|||
Organisationel |
|||
Logique |
|||
Technique |
Démarche par étape
-
Le schéma directeur
-
L'étude préalable
-
L'étude détaillée
-
La réalisation
-
La mise en œuvre
-
La maintenance
|
|
On verra ça plus tard |
4. Les flux
4.1. Notation
-
cerner le domaine qui nous intéresse
-
identifier les échanges
-
flux
-
acteurs
-
4.2. Exemples
4.3. Exercice
4.3.1. Enoncé
-
Une agence de location de voitures veut informatiser la gestion des locations.
-
Lorsqu’un client se présente à l’accueil, il précise le type de voiture désiré ainsi que la durée de location.
-
L’accueil vérifie si la location est possible et donne la réponse au client.
-
Si c’est le cas, la facture est éditée et donnée au client.
-
Celui-ci doit payer immédiatement.
-
Le paiement et la facture sont transmis au service comptable.
-
L’accueil transmet alors la demande au garage.
-
Ce dernier va préparer le véhicule demandé et le mettre à disposition du client.
4.3.2. Solution
-
1 : demande de location
-
2 : acceptation ou refus
-
si acceptation :
-
3 : facture
-
4 : paiement
-
5 : détail location + paiement
-
6 : détail demande
-
7 : véhicule
-
4.4. Règles de conception
|
|
Dans de rares cas, on représentera tout de même les flux entre certains acteurs externes pour une meilleure compréhension du système. |
4.5. Erreurs classiques
-
un acteur n’est pas un objet
-
un flux n’est pas un mouvement d’acteur
4.6. Modèle Conceptuel des Flux
-
Pas de représentation des acteurs internes
-
Juste le domaine et ses échanges avec les acteurs externes
-
Vue "boîte noire"
| Flux | Traitements | Données | |
|---|---|---|---|
Conceptuel |
MCF |
||
Organisationel |
|||
Logique |
|||
Technique |
4.7. Modèle Organisationnel des Flux
-
Représentation des acteurs internes
-
De leurs échanges avec les acteurs externes
-
Vue "boîte blanche"
-
Doit être cohérent avec le MCF correspondant
| Flux | Traitements | Données | |
|---|---|---|---|
Conceptuel |
MCF |
||
Organisationel |
MOF |
||
Logique |
|||
Technique |
4.8. Exercice : gestion de Carte Bleue
-
Le demandeur désirant obtenir une carte bleue doit en faire la demande auprès d’un employé de son agence. La carte bleue n’est accordée que si le demandeur est un client de l’agence.
-
Chaque jour, un employé de l’agence transmet au centre de gestion des cartes bleues les demandes des clients. Dès que le chef d’agence reçoit la carte bleue en provenance du centre (en général 4 jours après la demande), il adresse au client un avis de mise à disposition et un avis de prélèvement de la cotisation annuelle.
-
Le client vient alors retirer sa carte auprès du chef d’agence. Si au bout de 2 mois la carte n’a pas été retirée, elle est détruite.
4.9. Correction : gestion de Carte Bleue
-
Détermination des acteurs externes
-
Réalisation du MCF
-
Détermination des acteurs internes
-
Réalisation du MOF
|
|
MCF 1. Demande CB 2. Refus 3. Demande Groupée CB 4. Livraison CB 5. Avis de mise à disposition et avis de prél. 6. Retrait de la carte |
|
|
MOF 1. Demande CB 2. Refus 3. Demande Groupée CB 4. Livraison CB 5. Avis de mise à disposition et avis de prél. 6. Retrait de la carte |
5. Les traitements
5.1. Objectifs
-
Déterminer des processus
-
A partir des acteurs et des flux d’information
-
Notion de rôles de gestion
-
Concepts
-
les événements
-
les opérations
-
les résultats
-
la synchronisation
-
5.2. Diagrammes
- Modèle Conceptuel de Traitement (MCT)
-
Répondre au QUOI?
- Modèle Organisationnel de Traitement (MOT)
-
Répondre au QUI fait QUOI et QUAND?
| Flux | Traitements | Données | |
|---|---|---|---|
Conceptuel |
MCT |
||
Organisationel |
MOT |
||
Logique |
|||
Technique |
5.3. Notation
-
événements
-
synchronisation
-
opération
-
Règles d’émission
-
Résultats
5.3.1. Modèle Conceptuel de Traitement
Eléments importants
-
Fiches de poste
-
Tâches
-
Evénements déclencheur
-
Actions
-
Résultats
-
-
-
Opération
-
Événements déclencheurs
-
Synchronisation éventuelle (règles logiques)
-
Résultats
-
Règles d’émission
| Flux | Traitements | Données | |
|---|---|---|---|
Conceptuel |
MCT |
||
Organisationel |
MOT |
||
Logique |
|||
Technique |
Exemples
Récapitulatif de la démarche (MCT)
-
Identifier les postes
-
Définir les tâches
-
Déterminer les opérations
-
Associer les événements déclencheurs
-
Déterminer les résultats
-
Décrire les règles d’émission
Règles de bonne conception (MCT)
-
Regroupement de tous les traitements effectués dès l’arrivée d’un événement
-
Ne pas tenir compte de l’organisation interne du domaine étudié (répartition du travail entre acteurs internes)
-
Seule l’attente d’événements externes (=flux externes) justifie le découpage en plusieurs opérations
-
2 opérations consécutives liées exclusivement par des flux internes doivent être fusionnées.
-
Réutiliser les acteurs externes, les autres domaines et les flux externes trouvés dans le MCF
Evénements déclencheurs
- Evénement externe
-
Arrivée d’une cde, dde du client…
- Evénement temporel
-
18h, tous les lundis matin…
- Evénement interne
-
résultat d’une opération précédente
Synchronisation
Opérateurs :
-
ET
-
OU
-
NON
-
( )
-
combinaisons multiples
|
|
|
Actions
-
Types d’actions :
- action sur un objet
-
création, lecture, modification, suppression
- action résultat
-
impression, …
-
Conditions
-
une action peut être soumise à condition
-
Règles d'émission
- Règle d'émission
-
résultat de l’action
- Nombre
-
1 ou plusieurs
|
|
|
Résultats
-
Evénement résultat externe
-
impression, mail, coup de téléphone…
-
-
Evénement résultat interne
-
déclencheur d’une opération
-
changement d'état d’un objet
-
|
|
Une opération possède au moins un événement résultat par règle d'émission. Un résultat externe est toujours dirigé vers un acteur externe ou un autre domaine. |
Exercice
-
Lorsqu’un client envoie un bon de commande, il faut vérifier, pour chacun des articles, si le stock est suffisant pour la quantité commandée :
-
si c’est le cas, on enregistre la date de livraison, on met à jour le stock et on imprime un bon de livraison pour le service Livraison;
-
sinon le stock à réapprovisionner est incrémenté de la quantité commandée.
-
5.3.2. Modèle Organisationnel de Traitement
Eléments importants
-
Prise en compte de l’organisation interne
-
Cerne l’activité de
-
chaque poste de travail (informatique ou non),
-
chaque service
-
-
Prise en compte
-
Du « planning »
-
du type de ressources (manuel, automatisé),
-
du type de support (document écrit, magnétique etc.)
-
| Flux | Traitements | Données | |
|---|---|---|---|
Conceptuel |
MCT |
||
Organisationel |
MOT |
||
Logique |
|||
Technique |
Exemples de MOT
Règles de bonne conception d’un MOT
-
Examiner les traitements effectués par chaque acteur interne lorsqu’il reçoit un flux
-
Une tâche = un ensemble ininterrompu d’actions effectuées par un même acteur interne
-
Un MOT représente un processus c’est à dire un ensemble de tâches consécutives concourant à un même but
-
Les événements initiaux déclenchant un processus sont, soit des flux externes, soit des événements temporels
Exemple 1
-
Lorsqu’un agent d’une compagnie d’assurances automobiles reçoit une déclaration d’accident de la part d’un assuré, il vérifie tout d’abord la situation de ce dernier.
-
Si l’assuré n’est pas couvert pour ce type d’accident alors l’agent lui envoie un avis de rejet.
-
Tous les soirs à 18h, un traitement automatique édite les avis de sinistre de la journée (ces avis correspondent aux déclarations d’accident du jour pour les assurés couverts). Ces avis sont expédiés par l’agent au siège social de la compagnie d’assurance.
-
Le siège social désigne alors un expert pour chaque sinistre et envoie les coordonnées des experts désignés à l’agent d’assurance. Ce dernier envoie alors une convocation manuscrite à chaque expert.
-
Lorsque l’agent d’assurance a reçu le rapport de l’expert et la facture de l’assuré (cette facture a été produite par le garage qui a effectué les réparations sur le véhicule accidenté et a été ensuite donné à l’assuré propriétaire du véhicule), il peut régler le sinistre en envoyant un chèque de remboursement à l’assuré.
Exemple 2
-
A partir des demandes d’approvisionnement établies par le service commercial, le service des achats envoie des demandes de prix aux fournisseurs possibles.
-
Les fournisseurs envoient des offres de prix au service achat. Ce dernier choisit alors un fournisseur particulier (au plus tard 10 jours après l’envoi des offres) et lui envoie un bon de commande. Une copie est conservée en vue de la réception.
-
Quand la livraison arrive (généralement 2 jours après le choix du fournisseur), le service achat contrôle quantitativement et qualitativement la marchandise. La livraison est renvoyée en bloc si l’un des contrôles est négatif.
-
Les contrôles satisfaisants aboutissent à l’entrée en stock des articles. Dans ce cas, le service achat établit alors le bon à payer aux services financiers. Quand les services financiers reçoivent la facture du fournisseur (généralement 3 jours après la livraison), ils vérifient la correspondance avec le bon à payer et émettent le chèque de paiement.
-
A partir des demandes d’approvisionnement établies par le service commercial, le service des achats envoie des demandes de prix aux fournisseurs possibles.
-
Les fournisseurs envoient des offres de prix au service achat. Ce dernier choisit alors un fournisseur particulier (au plus tard 10 jours après l’envoi des offres) et lui envoie un bon de commande. Une copie est conservée en vue de la réception.
-
Quand la livraison arrive (généralement 2 jours après le choix du fournisseur), le service achat contrôle quantitativement et qualitativement la marchandise. La livraison est renvoyée en bloc si l’un des contrôles est négatif.
-
Les contrôles satisfaisants aboutissent à l’entrée en stock des articles. Dans ce cas, le service achat établit alors le bon à payer aux services financiers. Quand les services financiers reçoivent la facture du fournisseur (généralement 3 jours après la livraison), ils vérifient la correspondance avec le bon à payer et émettent le chèque de paiement.
5.3.3. Modélisation du futur Système
MOT/MOF Futurs
-
Degré d’automatisation
-
Automatisée : aucune intervention humaine
-
Conversationnelle (ou Interactive) : utilisation de l’informatique par l’humain
-
Manuelle : aucune intervention informatique
-
-
Délai de réponse
-
Immédiat : dès l’arrivée de l’événement déclencheur
-
Différé : après l’arrivée (délai sur décision ou chrono)
-
-
Mode de fonctionnement
-
Unitaire : la tâche s’effectue à chaque flux entrant
-
Par Lot : plusieurs flux d’entrée avant lancement
-
|
|
Certaines combinaisons plus fréquentes
|
|
|
Certaines implications
|
|
|
Possibilité de compléter les informations
|
Exemple de tâche de MCT futur
5.4. Définitions (récapitulatif)
Représentation d’un échange d’informations entre deux acteurs du domaine étudié ex: livraison, paiement
-
Composants du système étudié (acteurs internes) ou ayant une relation avec le système étudié (acteurs externes)
-
ex: étudiant, client, comptable
-
Fait susceptible de déclencher une opération
-
ex: commande, échéance (date)
-
Ensemble d’actions (non interruptibles) conditionnées par aucun agent extérieur autre que l’événement déclencheur
-
ex: prise en charge d’une demande
-
Centre d’activités élémentaires regroupant zéro, une ou plusieurs personnes, utilisant du matériel ou pas, faisant l’objet d’une ou plusieurs occurrences sur le terrain.
-
Ensemble homogène d’activités élémentaires résultant de la décomposition d’une opération conceptuelle.
-
Est associée à un poste de travail ;
-
A un niveau d’automatisation :
-
Manuelle (M),
-
Interactive ou Conversationnelle ©,
-
Automatique (A) ;
-
-
A un délai de réponse :
-
Immédiat (I),
-
Différé (D) ;
-
-
A un fonctionnement :
-
Unitaire (U) ou
-
par Lot (L) ;
-
6. Les niveaux logiques et techniques?
Pourquoi a-t’on décidé de "zapper" ces niveaux…
7. Les données
8. Références utiles pour cette partie
Partie 3 : SI
Partie 4 : SI et Organisations
Partie 5 : UML
Partie 6 : Conception des IHM
Plan de cette partie :
-
Généralités
-
Le modèle conceptuel d’IHM – Le SNI
-
Construction du SNI en mode esquisse
-
Construction structurée (patrons d’IHM)
-
Les IHM orientées fenêtres (GUI) – Le SEF
-
Les IHM orientées page (PUI) – Le SEP
1. Généralités
Les trois types de programmes :
-
Les programmes qui ne communiquent pas avec les utilisateurs (contrôles de processus)
-
Les programmes qui communiquent de façon indirecte (batch)
-
Les programmes interactifs (ceux qui nous intéressent :-)
Les types d’IHM :
-
Les IHM orientées texte : TUI (Text User Interface). Sur Mainframes ou Unix essentiellement.
-
Les IHM orientées fenêtres : GUI (Graphic User Interface). Sous Windows, Mac-OS …
-
Les IHM orientées pages : PUI (Page User Interface). Internet, Intranet, Extranet (HTML ou XML)
-
Les IHM Multimodales : vocales, tactiles …
2. Le modèle conceptuel d’IHM – Le SNI
Il n’existe pas de modèle de description d’IHM en UML ou en Merise. Nous allons donc voir le SNI de la méthode MACAO.
2.1. Objet
Le SNI permet de concevoir et de modéliser la logique d’enchaînement des fonctions de l’application en fonction du comportement supposé de l’utilisateur.
Le SNI est purement conceptuel :
-
il est indépendant du type d’interface utilisé (Windows, WEB, Multimédia…)
-
il ne représente pas la manière de faire de l’utilisateur (menu déroulant, bouton, glisser-déposer…)
-
il fait abstraction de tout aspect matériel (clavier, type d’écran, souris…)
-
il ne représente pas les traitements réalisés dans l’application
2.2. SNI et MVC
Le SNI concerne de la partie "Vue" du MVC.
2.3. Les Unités de Dialogue
On appellera "Unité de Dialogue" (UD) l’ensemble des fonctions offertes à l’utilisateur de façon simultanée (sur un même écran, dans une même fenêtre, dans une même page).
Chaque UD est représentée par un ou plusieurs symboles dans le SNI.
|
|
Une UD élémentaire = un seul symbole |
2.3.1. Les UD élémentaires (UDE)
2.3.2. Les UD composées par juxtaposition (UDC)
2.3.3. Les UD composées par boîte de groupage (UDC)
2.4. Construction du Schéma Navigationnel d’IHM (SNI)
Deux modes de construction
-
Mode esquisse (construction progressive)
-
Mode conception (construction structurée)
2.4.1. Règles communes
|
|
Règles des retours implicites
Après une UDE, le retour implicite s’effectue sur l’UD précédente. Après une option d’un menu juxtaposé à une UD (élémentaire ou composée) le retour implicite s’effectue sur l’UD juxtaposée. |
|
|
Filtres associés aux listes
Permet de restreindre le nombre de lignes d’une liste. |
|
|
Tris multiples des listes
Permet de trier une liste de différentes façons. |
|
|
Rôles et conditions d’accès
Les rôles et les conditions d’accès permettent de contraindre les accès aux menus
( |
2.4.2. Construction du SNI en mode esquisse
Au cours de l’acquisition des exigences ou
En rétro-conception d’IHM :
-
A partir des besoins des utilisateurs "
-
Cas d’utilisation et fonctions
-
Droits et conditions d’accès
-
Contraintes diverses
-
-
Participation des utilisateurs
2.4.3. Construction structurée (patrons d’IHM)
-
Pour les applications importantes
-
Adoption du principe OBJET-ACTION
-
Dans une approche objet-action on demande en premier lieu à l’utilisateur d’indiquer quels sont les objets sur lesquels il désire travailler puis, quelles opérations il veut leur appliquer.
-
-
Exemple d’illustration :
-
Soit une base de données comportant trois types d‘objets : CLIENTS, PRODUITS, FOURNISSEURS
-
L’utilisateur désire effectuer trois types d’actions générales sur ces objets : CONSULTER, MODIFIER, SUPPRIMER
-
Il désire également réaliser trois traitements spécifiques :
-
Lister les clients triés par régions,
-
Imprimer la fiche de stock d’un produit donné,
-
Marquer tous les fournisseurs dont le chiffre d’affaires est < 1000 €
-
-
2.4.4. Mise en oeuvre du principe OBJET-ACTION
Démarche
-
On part du diagramme des classes métier
-
Classes et attributs
-
Relations (associations, compositions, spécialisations)
-
Méthodes utilisateur
-
-
Utilisation de patrons de conception (Design Patterns)
Le SNI obtenu représente alors le squelette du SNI final.
-
Le squelette est complété avec
-
Les filtres
-
Les droits et conditions d’accès
-
L’accès aux fonctions
-
-
Le SNI est optimisé en cherchant à minimiser le nombre d’actions utilisateur (clics souris)
Exemple
Les exigences :
-
Afficher la liste de tous les étudiants classés par année, groupe et ordre alphabétique
-
Imprimer la liste
-
Afficher le détail d’un étudiant
-
Modifier l'étudiant affiché
Complément 1 : Nouveaux étudiants et Constitution groupes
Complément 2 : Gestion complète des groupes
Complément 3 : Saisie des notes d’un partiel
2.4.5. Patrons d’IHM
Cinq patrons d’IHM obtenus à partir du diagramme des classes
-
Racine (classes ciblées)
-
Détail (sélection d’un objet dans une liste d’objets)
-
Liaison (association entre plusieurs classes)
-
Aiguillage (spécialisation-généralisation)
-
Administration (mise à jour, création, suppression d’objets)
Patron Racine (classes ciblées)
-
Ciblage des classes métier
-
Mettre en évidence les classes prépondérantes, dont les objets seront présentés au premier niveau de l’IHM
Patron Détail (sélection d’un objet dans une liste d’objets)
-
Représenter tous les attributs d’un objet désigné dans une liste.
Patron Liaison (association entre plusieurs classes)
-
Suivre les liens entre les objets appartenant à des classes liées par des associations multiples (
*)
Patron Aiguillage (spécialisation-généralisation)
-
utile pour présenter les détails d’une généralisation
Patron Administration (mise à jour, création, suppression d’objets)
-
utile pour matérialiser un CRUD limité à l’administrateur
3. Les IHM orientées fenêtres (GUI) – Le SEF
Cette partie, réalisée en 1ère année de DUT en 2011/2012, n’est pas encore intégrée à ce support. Elle est proche du [SEP].
4. Les IHM orientées page (PUI) – Le SEP
Ni Merise ni UML n’ont de schémas spécifiques pour représenter les interfaces graphiques, ni les enchaînements des pages dans un site web par exemple. On peut par exemple utiliser un diagramme d'état UML où chaque état est une page et les transitions représentent les événements qui font passer d’une page à l’autre.
La méthode MACAO, déjà évoquée introduit plusieurs schémas utiles à cet effet, que nous allons reprendre dans ce cours. Le livre de Pascal Roques [Roques2007a] reprend par exemple ce genre de diagramme dans sa démarche globale de conception de site web.
Le SEP (Schéma d’Enchaînement des Pages) que nous voyons ici complète le SNI vu précédemment (cf. SNI).
4.1. Concepts des PUI
On peut distinguer 4 types de pages :
-
Pages de cadres
-
Pages de présentation constantes
-
Pages de présentation variables
-
Pages de formulaires
4.1.1. Pages de cadres (Frameset)
Un cadre est un découpage rectangulaire pouvant accueillir une page HTML (y compris une autre page de cadres).
Une page de cadre est divisée en deux ou plusieurs cadres occupant la totalité de la page.
4.1.2. Pages de présentation constantes
Pages ne contenant que des objets visuels constants statiques et des objets de navigation :
-
boutons d’action
-
zones réactives
-
liens hypertextes
|
|
Pages rencontrées habituellement en surfant sur le Net. |
4.1.3. Pages de présentation variables (ou pages dynamiques)
Analogues aux précédentes mais comportant en plus des données variables obtenues par calcul ou lues dans des fichiers ou des bases de données.
Méthodes d’obtention :
-
CGI (Common Gateway Interface),
-
ASP (Active Server Pages) de Microsoft, PHP d’Open Source
-
OAS (Oracle Application Server)
-
JSP (Java Server Page)
-
Servlet Java
-
…
4.1.4. Pages de formulaires
Pages contenant des objets de saisie (équivalentes aux boîtes de dialogue de saisie)
-
zones de textes (champs d’entrée)
-
boutons radios, cases à cocher
-
listes déroulantes
4.1.5. Les types d’objets visuels
Une page peut contenir 3 catégories d’objets :
-
Objets de positionnement
-
Objets non référencés
-
Objets référencés
Les objets de positionnement
Ils permettent d’indiquer les zones d’interaction avec l’utilisateur.
On trouve :
-
le cadre ne pouvant apparaître que dans une page de cadres
-
le signet (ou ancre d’arrivée) indiquant un point de chute possible dans une page
-
les objets de présentation et de mise en page : tableaux
<TR>,<TD>, divisions de pages<DIV>…
Les objets non référencés
Ils ne sont utilisés que pour les affichages statiques et n’ont pas besoin d'être identifiés de façon précise.
On trouve :
-
les statiques fixes : textes (ou labels), images (gif, jpeg…), encadrements, figures géométriques
-
les statiques animés : textes défilants, images animées (gif animé, vectorielles de type Flash…) scènes vidéo (mpeg, avi…), séquences audio (wav, mp3…)
Les objets référencés
Ils permettent d’assurer les interactions utilisateur : actions, saisie, navigation
On trouve :
-
les objets actifs de navigation : boutons d’actions simples ou sensitifs, liens vers les autres pages, liens hypertextes vers des URL (Uniform Resource Locator) ou des signets, zones réactives, zones de courrier électronique
-
les contrôles de formulaires : boutons (d’action, case à cocher, radio), champ d’entrée (simple, multilignes, de mot de passe), listbox (simple ou déroulante)
4.2. Principes ergonomiques
Cette partie fait l’objet dans le cours de DUT d’une intervention particulière, par une professionnelle de l'érgonomie. Nous reprenons simplement ici quelques grands principes.
Utilisez des divisions pour placer les informations répétées sur plusieurs pages : menus, en-têtes…
Utilisez des tableaux plutôt que des listes déroulantes
Les règles de structuration des boîtes de dialogue sont applicables la plupart du temps (alignement des champs affichés, regroupement des contrôles par famille, …)
Effectuez les « contrôles de surface » en local (fonction javascript par exemple)
Utilisez des polices standard (Arial, Times, Verdana)
Utilisez plutôt des fonds de pages clairs et une écriture sombre
Utilisez des feuilles de styles (CSS) pour les polices et les balises de présentations de textes : <A>, <H1>…
4.3. Le SEP
4.3.1. Codification
Caractéristiques générales :
-
Nom de la page précédé de son type : PCA, PPC, PPV, PFO
-
[ Droit d’accès ] ou [ Condition ]
-
"DESSIN", "MAQUETTE" ou "DESCRIPTIF" pour les pages complexes
-
( Paramètres ) : paramètre obligatoire souligné
-
FILTRE : <valeur du filtre> ; TRI : <attributs et sens>
-
CADRE : <nom du cadre d’accueil>
-
"FENETRE" si la page doit s’ouvrir dans un autre fenêtre navigateur
-
"POPUP" si la page doit s’ouvrir dans une fenêtre popup
4.3.2. Exemples de pages
4.3.3. Construction du SEP à partir du SNI
4.4. Dessin des pages complexes
4.4.1. Généralités
4.4.2. Formulaires
4.4.3. Exemples
4.5. Les dessins complexes
Un certain nombre d’outils existent pour faire des dessins complexes. Le prototypage rapide d’interface graphique est important pour valider au plus tôt les besoins du client (au moins en terme d’interface).
Nous n’en donnons que quelques-uns ici.
Partie 7 : Génie Logiciel
Partie 8 : UML Avancé
Dans cette partie, nous allons aborder une démarche générale de conception. Nous allons aborder des diagrammes UML comme le diagramme des cas d’utilisation ou de séquences. Dans nos enseignements de DUT Informatique, cette partie est abordée en 3ème semestre.
n’est donné ici qu'à titre d’exemple. Aucune démarche n’est associée à UML et nous faisons une agrégation ici des meilleures pratiques entre UML et Merise.
Pour continuer avec l’image de l’architecte, il s’agit pour lui de s’assurer, par une démarche systématique, du succès de son projet.
Plan de cette partie :
-
Le Diagramme des Cas d’Utilisation
-
Opérations, Paquetages et Java
-
Le Diagramme de Séquence
-
L’Architecture MVC
-
Schéma d’Enchaînement des Pages (SEP)
-
Les Dessins d’Etats imprimés
-
Une démarche complète
-
Analyse Globale
-
Conception Globale
-
Développement
-
Finalisation
-
Equivalence DC – MCD
1. Le Diagramme des Cas d’Utilisation
Le Diagramme des Cas d’Utilisation est un modèle UML permettant de représenter :
-
les UC (Use Case ou Cas d’Utilisation)
-
les acteurs (principaux et secondaires)
-
les relations entre acteurs et UC
|
|
On notera simplement |
1.1. Définition et concepts
1.1.1. Cas d’Utilisation (Use Case ou UC en abrégé).
Un cas d’utilisation représente un ensemble de scénarios que le système doit exécuter pour produire un résultat observable par un acteur.
Exemple d’UC
Retrait par carte bancaire
- Scénario principal
-
L’UC démarre lorsque le Guichet Automatique Bancaire (GAB) demande au client son numéro confidentiel après l’introduction de sa CB. Le client entre son code et valide son entrée. Le GAB contrôle la validité du code. Si le code est valide, le GAB autorise le retrait et l’UC se termine.
- Scénario alternatif n°1
-
Le client peut à tout instant annuler l’opération. La carte est éjectée et l’UC se termine.
- Exemple de codification de l’UC
-
UC01 ou RetraitCB (pour Retrait par carte bleue)
Précisions
Un cas d’utilisation peut être précisé par :
-
une description textuelle
-
un ou des diagrammes UML (séquence, activité)
|
|
Dans les outils, cette "précision" se manifeste par le fait que l’on "attache"
généralement un diagramme de séquence à un cas d’utilisation (clic droit sur un UC → nouveau |
1.1.2. Acteur
Un acteur peut être une personne, un ensemble de personnes, un logiciel, un processus qui interagit avec un ou plusieurs UC.
On peut trouver plusieurs types d’acteurs :
-
extérieurs au système (cf.
actorDiagramme d’UC ci-après)-
les acteurs principaux (= acteurs internes du MOT de Merise)
-
les acteurs secondaires (= acteurs externes du MOT de Merise)
-
les administrateurs (ils gèrent le système : données, sécurité, droits d’accès, utilisateurs…)
-
-
types d’acteurs prédéfinis dans UML :
-
<<metaclass>> -
<<utility>> -
<<process>> -
<<thread>> -
<<powertype>>
-
1.1.3. Relations entre UC
-
Extension (
<<extend>>) -
Indique que l’UC source est éventuellement exécutée en complément de l’UC destination (cas particulier, erreur…)
-
Inclusion (
<<include>>) -
Indique qu’un UC est inclus obligatoirement dans un autre UC (notion de sous-programme par exemple)
- Généralisation
-
Relation entre un UC général et un autre plus spécialisé qui hérite de ses caractéristiques et en rajoute
|
|
On n’utilise généralement |
1.2. Pour construire un UC (de manière générale)
-
identifier les acteurs
-
identifier les cas d’utilisation
-
structurer en packages
-
ajouter les relations
-
finaliser les diagrammes de cas d’utilisation
1.3. Obtention des UC dans le cadre de ce cours
Deux cas peuvent se présenter :
- Un nouveau MOT a été construit
-
Chaque tâche informatique du nouveau MOT devient un UC
- Un MOT n’a pas été nécessaire
-
Les cas d’utilisation doivent directement être extraits des interviews d’utilisateurs ou des compte-rendus de réunions (cf. cas général ci-dessus).
1.4. Exemples complets
1.4.1. Service comptable
1.4.2. Gestion des notes
1.4.3. Liens entre SNI et UC
2. Opérations, Paquetages et Java
2.1. Opérations
Un ensemble d’opérations définit le comportement de l’objet (ex : setVitesse(valeur)),
c’est à dire son interface.
2.2. Opérations et Visibilité
- L'encapsulation
-
-
facilite l'évolution d’une application car elle stabilise l’utilisation des objets. On peut modifier l’implémentation des attributs d’un objet sans modifier son interface
-
garantit l’intégrité des données, car elle permet d’interdire l’accès direct aux attributs des objets (utilisation d’accesseurs). Un objet n’est manipulable qu’à travers son interface
-
|
|
Rappel : chaque opération a un argument implicite qui est l’objet sur lequel elle porte. Exemple : |
- Type d’opérations
-
Un accesseur
getX()permet de consulter l’attributXde l’objet, le modificateursetX(val)permet de modifier la valeur de l’attributXavec le paramètreval. Par défaut, on doit avoir un accesseur par attribut privé. - Visibilité
-
Il existe 4 niveaux de visibilité des attributs et des opérations :
-
-privé (l’élément n’est visible que par la classe) -
+public (l’élément est visible par toutes les autres classes) -
#protégé (l’élément est visible par la classe et ses sous-classes) -
~package (l’élément est visible par la classe et les classes du même paquetage)
-
2.3. Paquetages
Les paquetages permettent de regrouper les éléments de modélisation. Ils peuvent contenir d’autres sous-paquetages sans limites de niveaux.
Le paquetage est un espace de nommage.
Un paquetage peut importer une classe issue d’un autre paquetage.
Exemple : Vehicules::Voitures signifie que la classe Voiture est importée du paquetage Vehicules.
|
|
On emploiera souvent dans ce cours le terme anglais de package pour désigner un paquetage. |
2.4. Génération de code
Voici quelques exemples de diagramme de classes et du code java associé.
2.4.1. Classe
Catalogue du package Cataloguepackage Catalogue; import java.util.Date; public class Catalogue { private String nom; private Date dateCreation; public Catalogue() { ... } public Livre chercherLivre(String isbn) { ... } }
2.4.2. Généralisation
Adherent hérite de Personnepublic abstract class Personne { private String nom; private String prenom; protected Date dateNaissance; private static int ageMajorite = 18; public abstract int calculerDureePret() {... } public static void setAgeMajorite (int aMaj) {... } } public class Adherent extends Personne { private int iD; public Adherent() { ... } public int getAge() { ... } public int calculerDureePret() { ... } }
2.4.3. Associations
public class A1 { private B1 leB1; } public class A2 { private B2 lesB2[ ]; } public class A3 { private List lesB3 = new ArrayList(); }
2.4.4. Dépendance
package Bibliotheque; import Catalogue; public class Bibliotheque { private Catalogue leCatalogue; ... }
2.4.5. Equivalences entre diagramme de classes
2.4.6. Classe Association
public class Emploi { private String titre private Double salaire; private Employe salarie; private Societe employeur; ... }
3. Le Diagramme de Séquence
3.1. Généralités
-
Modélise les interactions entre objets
-
Séquencement dans le temps
-
Échange de messages
-
Spécifie les scénarios des cas d'études
-
Éléments :
-
participants
-
lignes de vie
-
barres d’activation
-
messages
-
|
|
Les lignes de vie représentent des objets et non des classes |
3.2. Exemple
3.3. Notions avancées
-
Instructions itératives et conditionnelles
-
Mieux vaut utiliser un diagramme d’activité
-
Cadres d’interaction
-
loop(boucle) -
alt(alternative) -
opt(optionel) -
par(parallèle) -
region(région critique - un seul thread à la fois)
-
3.4. Exemple de conceptions
3.5. Diagramme de séquence système
Bien que non présent dans UML, il est courant de trouver un diagramme de séquence particulier, le diagramme de séquence système ou DSS, où on ne représente qu’un seul objet : le système en cours de développement lui-même.
3.6. Lien entre UC, DSS et DS
La décomposition hiérarchique permet de réaliser une description "TOP-DOWN" du système à réaliser.
On fait un Diagramme de Séquence Système pour chaque UC (issu du Diagramme d’UC) pour déterminer les échanges d’informations entre l’acteur et le système.
Ensuite on fait un Diagramme de Séquence (DS) pour décrire comment les objets composants le système (issus du Diagramme de Classes) collaborent pour réaliser le traitement demandé.
4. Le paradigme MVC
Le paradigme Modèle-Vue-Contrôleur, ou MVC (de l’anglais Model-View-Controller) est une architecture logicielle qui divise l’application en trois éléments importants (cf. MVC ci-dessous) :
- le modèle
-
chargé de gérer les élements d’information (comme la base de donnée)
- les vues
-
interfaces entre l’application et l’utilisateur
- les contrôleurs
-
chargés de faire le lien entre vues et modèle.
L’avantage de ce patron d’architecture :
-
la clarté qu’il impose,
-
la simplification de maintenance du logiciel. La modification d’une partie (vue, modèle ou contrôleur) n’affecte pas ou peu les autres parties.
|
|
Le MVC est issu d’un modèle de programmation des applications interactives proposé par Xerox pour le langage Smalltalk-80, repris par SUN et recommandé pour la plateforme J2EE. |
La vue correspond à l’interface avec laquelle l’utilisateur interagit. Sa tâche est :
-
de présenter les résultats renvoyés
-
de recevoir toutes les actions de l’utilisateur (clic de souris, sélection d’une entrée, boutons, …)
Ces différents événements sont envoyés au contrôleur.
Le contrôleur gère les événements pour mettre à jour la vue ou le modèle et les synchroniser.
Il reçoit tous les événements de l’utilisateur et enclenche les actions à effectuer.
|
|
Le modèle contient les données manipulées par l’application. |
|
|
Il y a en général un contrôleur par UC. |
|
|
Les 3 packages présentés ci-dessus (cf. MVC regrouperont respectivement |
4.1. Exemple
4.2. Le Diagramme des Classes Participantes
Il s’agit des classes, issues des 3 paquetages MVC, qui "participent", dans un DS donné, à la réalisation d’un UC. On fait notamment apparaître les méthodes utilisées par le DS dans chaque classe.
4.3. Les MVC
En fonction des langages et des architectures, vous trouverez autant de schéma MVC différents que l’on peut en imaginer! Attention à vous adaptez.
Cette partie est traitée ici.
5. Les Dessins d’Etats imprimés
5.1. Objet
Les états informatiques doivent faire l’objet d’une analyse précise avant de procéder à leur programmation.
Dans ce but on utilise une grille d’imprimante (ou grille d’impression).
Cette grille est remplie à partir d’une maquette utilisateur (dessin rapide permettant de capter les besoins de l’utilisateur)
Le report de la maquette utilisateur sur une grille d’imprimante permet de réaliser une mise à l'échelle de l'état et de donner des instructions précises au programmeur.
5.2. Les familles d’imprimantes
5.2.1. Les imprimantes lignes
Elles sont généralement utilisées dans les grands centres d’impression.
L’impression est réalisée ligne par ligne avec un format fixe sur du papier en continu (pliage accordéon) muni de bandes d’entraînements latérales appelées bandes Carol.
Caractères utilisés : très limités (26 lettres et 10 chiffres et qq caractères spéciaux) Vitesse : en lignes par minutes. Elle peut varier de 200 à 2000 lpm.
5.2.2. Les imprimantes matricielles (ou à aiguilles)
Ces imprimantes fonctionnent avec une colonne d’aiguilles (9, 12, 24 … aiguilles) permettant d’imprimer les caractères sous forme d’un ensemble de points. Les aiguilles sont placées dans une tête d’écriture se déplaçant latéralement devant le papier.
Caract. utilisés : formes et tailles variées ainsi que mise en relief (gras, souligné, italique).
Vitesse : en cps (Caractères Par Seconde). Elle varie de 60 à 400 cps.
5.2.3. Les imprimantes à jet d’encre
Elles utilisent les mêmes principes que les imprimantes à aiguilles mais les aiguilles sont remplacées par une série de buses projetant un jet d’encre sur le papier : plus de silence et meilleure qualité d’impression.
5.2.4. Les imprimantes laser
Un rayon laser magnétise localement un tambour sur lequel est projetée une encre en poudre. L’encre est attirée par les régions magnétisées du tambour et se dépose sur le papier sur lequel elle est fixée par chauffage. Les imprimantes laser impriment directement une page complète.
Les caractères : tous
Vitesse : en ppm (Page Par Minute). 10 ppm environ
5.3. Les formulaires en continu
5.3.1. Les liasses
On appelle liasse une superposition de plusieurs feuilles de papier chimique (de 2 à 4) permettant d’imprimer simultanément plusieurs exemplaires d’un même état. Les liasses ne peuvent être utilisées qu’avec les imprimantes lignes ou matricielles (qui « frappent » le papier).
5.3.2. Les pré-imprimés
Certaines informations apparaissant sur les états peuvent être- pré- imprimées par un imprimeur (à partir d’une maquette qu’on lui aura fournie).
Caractéristiques du pré-imprimé :
-
+ meilleure qualité d’impression
-
+ temps d’impression réduit
-
- coût du papier plus important
5.4. La grille d’imprimante
5.4.1. Types d’informations
Il faut distinguer deux types d’informations apparaissant sur un état, les informations fixes et les zones variables.
- Les informations fixes
-
Elles correspondent aux différents titres et encadrements. Les informations pré-imprimées sont forcément des informations fixes (on les représentera en rouge sur la grille d’impression).
- Les zones variables (3 catégories)
-
les zones alphanumériques : format
COBOL X(n)
les zones numériques entières :formatCOBOL 9(n)
les zones décimales avec séparateur :9(n)V,9(m)
Chaque caractère, fixe ou variable, occupera une case de la grille d’imprimante.
5.4.2. Graphisme "ancien"
Utilisation d’étoiles, de i majuscules et de tirets :
5.5. Présentation générale des états
Il faut prévoir l’impression de la date d'édition de l'état (en haut à gauche). Dans le cas de listes se poursuivant sur plusieurs pages on rajoutera systématiquement les informations suivantes :
-
un num. de page en haut à droite, avec le nb total de pages (ex : 3/10)
-
une répétition des titres en haut de chaque page
Il faudra veiller à imposer des sauts de page (FF : Form Feed) à certains endroits.
5.5.1. Répétition de lignes et de blocs :
Si une ligne de variable se répète de façon identique sur plusieurs lignes, on indiquera la répétition en plaçant sous chaque variable une colonne de points. Des répétitions de blocs de lignes seront représentées par des accolades.
5.5.2. Numérotation des variables et légende :
De façon à ce que le programmeur puisse identifier correctement chaque variable, on procédera à leur numérotation de gauche à droite et de haut en bas sur la grille d’imprimante.
Le numéro sera porté au-dessus de chaque zone variable en utilisant une couleur différente de façon à ne pas les assimiler aux informations fixes.
Seules les variables de la première ligne seront numérotées si la ligne est répétitive.
Les numéros de variables seront reportés dans une légende qui sera placée sur la grille d’imprimante s’il y a de la place ou sur une feuille jointe. La légende portera les informations suivantes : numéro et nom de la variable, format d'édition COBOL.
6. Rappels sur les démarches
6.1. Généralités
Les grandes étapes :
-
Analyser
-
… puis Concevoir
-
… … puis Réaliser
Deux grandes écoles :
-
Projets en cascade
-
Analyse
-
Conception
-
Réalisation
-
-
Projets itératifs
-
Prototypage
-
Contrat de moyens et non de résultats
-
Liens MOA/MOE plus compliqués (cf. plus loin)
-
6.1.1. Analyser
-
Découvrir/décortiquer un domaine
-
Prendre en compte les besoins utilisateurs
-
Définir le problème à résoudre
-
Fonctionnalités
-
Qualités attendues
-
Environnement
-
-
Modéliser le tout
6.1.2. Concevoir
-
Définir une solution :
-
Structurer les données
-
Organiser les traitements
-
Définir les postes de travail
-
Adopter certaines techniques
-
6.1.3. Réaliser
-
Coder
-
Recoder une application existante (Refactoring)
6.1.4. Qualités requises
-
Pour bien analyser et concevoir :
-
Avoir une bonne capacité d’abstraction
-
Maîtriser la modélisation
-
Abstraire
-
Communiquer
-
-
Qualités relationnelles
-
Etre créatif
-
Avoir de la méthode
-
6.1.5. Rôles importants
Deux acteurs importants :
-
Maîtrise d’ouvrage (MOA)
-
Maîtrise d’oeuvre (MOE)
|
|
Définis par la loi! (n° 85-704 du 12 juillet 1985)
Le maître de l’ouvrage est la personne morale, …, pour laquelle l’ouvrage est construit. Responsable principal de l’ouvrage, il remplit dans ce rôle une fonction d’intérêt général dont il ne peut se démettre. Il lui appartient, après s'être assuré de la faisabilité et de l’opportunité de l’opération envisagée, d’en déterminer la localisation, d’en définir le programme, d’en arrêter l’enveloppe financière prévisionnelle, d’en assurer le financement, de choisir le processus selon lequel l’ouvrage sera réalisé et de conclure, avec les maîtres d’oeuvre et entrepreneurs qu’il choisit, les contrats ayant pour objet les études et l’exécution des travaux. |
6.1.6. Analyser, c’est difficile
Service de vente en ligne (jeBouquine.com)
6.2. Exemple complet de démarche "ad hoc" autour d’UML
Nous allons aborder une étude de cas tirée du livre de Pascal Roques.
|
|
Pour un apperçu du livre, cf. http://www.editions-eyrolles.com/Chapitres/9782212110708/chap01.pdf. |
6.2.1. Le cahier des charges
Il s’agit de développer un service de vente en ligne (http://jeBouquine.com).
6.2.2. Des besoins au code
6.2.3. Raffinement des besoins
6.2.4. Près du code
6.2.5. Comment trouver les classes ?
6.2.6. Comment trouver les interactions ?
6.2.7. Liens entre diagrammes
6.2.8. Démarche complète
6.3. Exemple d’une méthode industrielle
Nous allons rapidement survoler la méthode Neptune. Développée en collaboration avec des académiques (dont l’IRIT et des industriels (dont Communication & System), cette méthode couvre aussi bien le business model (modèle orienté "économique" qui aborde aussi bien le produit que des notions comme les objectifs, les opportunités, les processus, etc.) que le génie logiciel (software engineering) qui nous intéresse ici.
|
|
La méthode Neptune tire ses racines du Unified Process (cf. [RUP]). Elle est compatible avec la méthode de Pierre-Alain Muller (cf. [Muller]). Elle est supportée par un outil eclipse. Pour plus d’information, voir http://neptune.irit.fr/. |
6.3.1. Démarche globale
|
|
qui utilise le mieux la méthode Neptune. L’an dernier ce prix était de 1.500 €! |
Les grandes étapes de la démarche sont :
-
Analyse des besoins (Requirements Analysis)
-
Analyse objet (Object Analysis)
-
Conception architecturale (Architectural Design)
-
Conception objet (Object Design)
-
Conception physique (Physical Design)
Analyse des besoins
L’objectif de cette étape est de définir l’environnement du système et son utilisation.
Plusieurs activités concernent cette phase :
-
Définition des acteurs
-
Définition du contexte
-
Description du système
Analyse objet
L’objectif de cette étape est de commencer à organiser les classes déjà identifiées dans l'étape précédente et d’obtenir une première vue logique du système.
Une seule activité concerne cette phase :
-
Analyse objet
Conception architecturale
L’objectif de cette étape est de définir l’architecture du système.
Plusieurs activités concernent cette phase et se déroulent en parallèle :
-
Définition des composants logiciels
-
Description des composants logiciels
-
Identification des packages de conception
-
Application des patrons de conception (designs patterns)
Conception objet
L’objectif de cette étape est de développer pour chaque package une conception détaillée.
Plusieurs activités concernent cette phase :
-
Conception des classes
-
Mise en oeuvre du MVC et conception des modèles de données
Conception Physique
L’objectif de cette étape est de concevoir l’architecture physique de l’application.
Plusieurs activités concernent cette phase :
-
Description de l’architecture physique
-
Identification des processus et des composants
-
Allocation des classes
6.3.2. Analyse et vérification
L’intérêt de la méthode Neptune réside essentiellement sur le fait qu’elle insiste sur la phase de vérification des modèles. Très détaillée, cette activité dépasse le cadre de ce cours d’introduction.
|
|
Pour plus de détail, voir le livre en ligne http://neptune.irit.fr/images/files/NeptuneBook/407719ps.pdf. |
6.4. Au DUT Informatique de Blagnac
La démarche que nous utilisons au DUT est résumée par le diagramme ci-dessous.
Appendix A: Annexes
1. Exercices de révision
Reprendre ici les questions des chapitres (à organiser en fichiers!) et également le quizz.
2. Liens utiles
-
Merise
-
Blogs
-
Outils
-
Outils de dessins d'écrans complexes :
-
http://socialcompare.com/en/comparison/mockup-wireframing-design-tools
-
http://mockflow.comm (limitations pour la version gratuite)
-
http://iphonemockup.lkmc.ch/ (pour iphone)
-
Outils de production
-
Les conseils généraux de Scott Ambler sur Ecrire un livre technique
-
Les conseils techniques de Matthew Mc Cullough sur Ecrire un livre technique
-
-
Divers
-
Pour en savoir plus sur l’auteur
-
3. A propos de ce document…
4. FAQ
Cette Frequently Asked Question a été construite par expérience, en regroupant les questions des étudiants durant mes différentes interventions.
Cette FAQ peut servir de base à la révision d’examens.
4.1. Peut-on "séparer" un acteur externe en deux acteurs externes avec un statut différent.
(Par exemple, un acteur "Personne intéressée par l’achat d’un portable" et un autre acteur "Acheteur")
Oui, c’est toujours permis puisque les acteurs sont des rôles et non des personnes bien identifiées. La question qui se pose est : est-ce judicieux? Dans certains diagrammes on pourra restreindre l’usage de telle ou telle partie de l’application à tel ou tel rôle. Donc dans l’exemple ça semble intéressant de différentier (l’acheteur pourrait être identifié avec un login et un num de carte bleue, la personne intéressée ne l'étant pas par exemple, etc.).
4.2. Exemple
4.3. Divers
Quelques autres questions que je laisse à votre sagacité :
-
blabla
4.4. A propos de la production de documents par programmation
blabla …
Bibliographie
Les références…
-
[HighsmithFowler2001] Jim Highsmith and Martin Fowler. The agile manifesto. Software Development Magazine, 9(8) :29–30, 2001.
-
[1030005] Kieran Conboy and Brian Fitzgerald. Toward a conceptual framework of agile methods : a study of agility in different disciplines. In WISER ’04 : Proceedings of the 2004 ACM workshop on Interdisciplinary software engineering research, pages 37–44, New York, NY, USA, 2004. ACM.
-
[Roques2007a] Les Cahiers du Programmeur, UML2, Pascal Roques 3ème Edition, Eyrolles, 2007.
-
[Roques2007b] UML 2 par la pratique, Pascal Roques 6ème Edition, Eyrolles, 2007.
-
[Blanc2006] UML pour les développeurs, Xavier Blanc, Eyrolles, 2006.
-
[Longepe2006] Le projet d’urbanisation du S.I., C. Longépé, 3ème édition, Dunod, 2006.
-
[Gillet2008] Management des SI, M. & P. Gillet, Dunod, 2008.
-
[Muller] Modélisation objet avec UML. Pierre-Alain Muller & Nathalie Gaetner, Eyrolles, 2003.
Glossaire
|
|
Ressources
Les définitions ci-dessous sont regroupées à titre indicatif. Les sources utilisées sont :
|
- DRY
-
Don’t Repeat Yourself :
- IHM
-
Interface Homme-Machine
- MCF
-
Modèle Conceptuel des Flux
- MCT
-
Modèle Conceptuel des Traitements
- MOA
-
Maîtrise d’ouvrage (MOA) Maîtrise d’oeuvre (MOE)
- MOF
-
Modèle Organisationnel des Flux
- MOT
-
Modèle Organisationnel des Traitements
- OMG
-
Object Management Group : L’organisme international chargé des principales normes liés à l’objet (CORBA, UML, etc.).
- PPN
-
Programme Pédagogique National
- SEF
-
Schéma d'Enchaînement des Fenêtres
- SEP
-
Schéma d'Enchaînement des Pages
- SNI
-
Schéma de Navigation d'Interfaces
- SysML
-
System Modeling Language ™ : le langage de modélisation de systèmes maintenu par l’OMG.
- TRL
-
Technology Readiness Level : système de mesure employé par des agences gouvernementales américaines et par de nombreuses compagnies (et agences) mondiales afin d'évaluer le niveau de maturité d’une technologie (cf. Wikipedia).
- URL
-
Universal Ressource Locator